Thank you for watching.
Thank you for watching.
Thank you for watching.
Thank you for watching.
Now, most of these systems
here, at least for
today, they're based on signature analysis.
Quite similar to virus scanning technology from
years ago. So they rely on hard-coded
databases that they query for
suspicious patterns.
So, you know, if they see a
an IDS vendor will perform an attack,
log that attack on the wire, and see if they can come up with
a mechanism so that they will be able to identify it at any time.
Some of the drawbacks of this
system is that they require quite frequent updates.
As you can imagine, I mean, splices are written every five minutes, right?
So, you know, you've got to update these things,
keep them current, and that's kind of
an ongoing battle. You know, whenever something comes across bug track,
someone's got to go and, you know, identify whether or not this vulnerability
is actually, you know, real, and then generate some kind of signature for it.
These systems analyze data on the wire in a serial fashion. So, I mean, from
beginning to end, and try and match it against known systems.
Some other
probable ways that they could go about it is protocol analysis.
Now, you've got your intrusion detection system, and it's going to go,
okay, hey, this is my web server. It should only be performing a certain
amount of functions, right? So, when I see my web server, like, connecting back to
the client, you know, that might be something suspicious, right? Depending on,
like, their particular configuration and whatever, right? So, that would be a bad thing.
Also, some things on the horizon appear to be statistical analysis intrusion
detection systems. Now, these systems are primarily engineered with the
assumption that network data over a long period of time is self-similar. And
what that means is that, you know, a finite sample of, like, a week-long worth
of, like, traffic patterns can be extrapolated to, like, you know, an entire year, and it should be
fairly similar.
So, if these systems get going and you're able to identify good traffic throughout the
entire thing or process, in the long run, they should be able to identify any statistical
anomalies based on that baseline. Now, these things are under development, and I really
don't know any IDS vendor that really has something of that kind of quality or what-have-you.
Some of the invasion techniques that are currently employed by people are primarily on the network layer.
Now, this would entail stuff like IP fragmentation to confuse the intrusion detection system as to what
the traffic is going to end up looking like when it arrives at the destination host, as many hosts
reassemble fragments in, you know, various manners, and they might overlap in certain ways. So,
you know, some of the ways to defeat these systems in the past has been just to, like, overlap your packets or
send them out of order, or do what-have-you. A lot of these IDSs, some of them don't even look at
fragmented packets, so that was always like a really good way to get around them.
Oh, sorry. Excuse me.
I'm okay. I got a couple here.
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on. Now another invasion technique would probably be something like spoof data, right? Like
if I don't want the IDS sensor to know where I'm coming from, you know, that sure does
aid. Sure, they might see what I'm doing and pick up the data, but it doesn't really matter
if they can't tell where I was coming from, I suppose, right? I mean, that helps out in
certain ways. And also, you could spoof the origin from some ignored host, like a DNS
server or something like that that might have some special properties within the engine
of the IDS, right? So it goes, oh, if there's some traffic from this host, let's just ignore
it because it's so chatty. Some other things that we've got here that have been explored
quite heavily is on the application layer. And this primarily is in the realm of data
obfuscation. And what we're talking about here is, you know, with something like Unicode,
there might be like a half billion ways to print the letter A to the screen. And there
right? So if your exploit depends on the fact that you've got to have an A there, and
the IDS is just kind of geared towards an ASCII character set, which is kind of like
a subset of Unicode anyhow, it might miss some kind of like more advanced encoding mechanisms
that you might use. So again, this is another problem of the IDS, right? I mean, they've
got to account for, you know, God knows what the end system of the attack is going to be.
What is the attack going to do with this data? Does it support Unicode? Is this Unicode?
Or is it just going to interpret it in a different manner? So these are really hard things for
the IDS to kind of understand. You can use things like alternate character sets or what
have you, kind of along the same lines as that. And another technique that you could
possibly use is data encoding on the application layer. And that's pretty much what this particular
utility is doing.
It's all about, you know, we're going to encode the data in a way that every execution
of it coming across the screen is going to be unique. So in essence, your exploits are
always going to be zero-day regardless of signatures, right? Because the signatures
are designed to analyze a specific code and, you know, they're only good once they can
get it into the database.
But if you're able to have new codes every time being generated on the wire, then, I
mean, it seems reasonable that they won't be able to detect it.
Essentially, what this utility is going to do is work with buffer overflow exploits,
and it can possibly be adapted to format strings, any kind of shellcode or binary executing
stuff that you're going to send across the wire.
It's a good thing, though, that the utility's not going to be able to generate an entire
it should probably be able to help you out with.
I assume that most people have a fairly good understanding
of buffer overflows and there are weekly talks on this,
so you can just, I hope that you guys have at least
read a paper or something.
Now, you've got this beast that we all call shellcode,
which is essentially the arbitrary commands
that we're gonna be sending to the target system.
So the shellcode is encoded prior to the launch.
Each encoding, therefore, is unique,
and we're able to bypass signatures.
The decoder, what we have to do is once we encode
the shellcode, obviously, it isn't gonna function
when it lands on the target system, right?
So we have to prepend that with a decoder.
Now, this decoder itself will process the data
after it appears on the target host.
So, unfortunately, a lot of exploits are written
so that when you jump from
the,
into the NOPS section, you know, hopefully,
they wrote it good enough so they're jumping fairly close
to the beginning of these NOPs,
and not just like right at the end,
and they just kind of coded it, and it worked,
and they said, okay, killer, there we go.
Because, you know, we're gonna eat up a small portion
of those available NOPs.
So your shellcode is effectively like,
you know, increased in size.
So, I mean, even if the network intrusion detection
system were on the host that was being exploited, you know,
exploited, it would not be able to detect anything because this is all happening on
the application layer. And again, signature analysis, you know, it should be able to ‑‑
should be unable to match the shellcode or the decoder or the return addresses that are
normally placed at the tail end of your buffer overflow. This is because I incorporated a
number of primitives to modulate the return addresses based on your tolerances and stuff
like that. The decoder itself also is in a polymorphic form. Now, polymorphic is essentially
the ability to exist in multiple forms and be functionally identical. So, you know, we'll
go into that a bit later on. Oh, by the way, I mean, anybody feel free to pop up and ask
some questions. You know, I love interactive crowds.
What would be the best decoder?
It's extremely polymorphic, you know.
In the simple way that it is.
Well, currently, I only support one decoder because the encoder is in C and it's in the
API and it encodes it and sends it out. And I've just been concentrating on making it
cross-platform rather than adding, like, you know, tons and tons of bells and whistles
to the decoder right now. So I'm trying to get it across the platform.
It is polymorphic, but that's one variation currently?
Well, you'll see.
You're a fucking guy.
Are you going to tell me that you don't have, like, an intelligent decoder based on genetic
algorithms which actually adapt to any execution environment?
Actually, I just added, the question was whether or not I have genetic algorithms
based on, to detect, you know, to breed new decoders which are able to survive in the wild,
right?
Not currently.
You know, this is on the horizon.
Well, this is just the public version, Joey. I mean, come on, okay?
I think we had another question.
How many bytes of Knopsled do you take out?
You can configure that to your particular tolerances, right? So if you've got a
splite that you've only got, like, you know, 200 bytes worth of Knopsled, you can configure
the decoder to, you know, fine-tune how it behaves.
And, you know, I've had decoders as small as, like, you know, 40 bytes and as large
as 400.
So it's fairly, pretty much up to you.
Yes?
Oh, really?
You made me skip my slide, man.
Real men don't.
You know that you don't.
I don't use Knops.
There you go.
Now, the attack payload of a buffer overflow, just a brief overview, typically
consists of these three sections which we've got to...
You know, take a look at.
We've got this Knopsled, which is the initial portion.
We've got the shellcode in the middle.
And we've got these jumps at the back, you know, doing your framer register overwrites
or whatever the hell you're doing that will point back into the Knops somehow.
Now these three individual sections are what the IDSs will, you know, be focusing on, you
know, one of these three.
That was the Canadian beat.
Also format strings again, and we can adopt this for their use later on.
Knop substitutions.
Currently the Knop instructions at the beginning of the shellcode are substituted.
Now we've got an extensible list of possible replacements that can comply to whatever restrictions
that your particular code needs to adhere to.
For instance.
Let's say I need two upper compliant code, two lower compliant in space, or I've got
various band characters which can't appear in the generated shellcode.
This API will automatically generate that for you.
So if you've got...
If you don't really have any skills to, like, write that code yourself and you just want
to cut and paste, you know, you can try and see if it can identify a sequence that will
generate the code for you.
But the more restrictions you place on the encodings.
The more encoded shellcode, the, you know, obviously the less permutations you can actually
form.
Right?
I mean, I've had, you know, anywhere from three and a half billion possible shellcodes
or, you know, packets to send to, you know, 50, right?
Just because of certain restrictions in the exploit.
This note is primarily for Intel, the Intel architecture.
Okay.
So, traditionally, guys coding Intel stuff don't really have to worry about the alignment,
which is, like, where you're going to jump into the nops.
So if you're jumping in there and traditionally it's only a one byte nop instruction, if we
enable, like, multi-byte, you know, instructions to be in that section of the shellcode, you
know, there's the possibility that you're going to jump into the middle of an instruction
and not going to be able to execute in the way that you're going to be able to execute.
In the way that you normally would.
So, but, I mean, I would encourage the use of multi-byte nops because, I mean, this greatly
increases the, you know, the amount of codes that will appear within that section.
I think I've got about 28 right now.
So that's 28 out of a possible 255.
So like a little better than 10% of, you know, character space will be available in that
nop section.
You know, I've heard.
Okay.
From statistics, you know, degree guys, that, you know, this really isn't quite what you
need to have to be statistically resilient to analysis.
So if you enable these multi-byte, you know, features, that will allow you to have virtually
limitless amount of characters appearing within that nop slide.
Okay.
Now, Joy?
I haven't seen any IDS.
Okay.
Any IDS which can actually decipher bytecode encodings to actually see if it's actually
.
I mean, I'm trying to say, like, is there any IDS which is, like, not plain, basic,
stupid?
No.
They're all pretty dumb.
Like, they don't really have the current ability to analyze the instructions right now and
see exactly what they're doing or the data, per se, that I have seen.
Oh, the question was if I have seen any IDSs out there which can actually intelligence.
Yeah.
And, you know, intelligently analyze the data sections of these attacks and actually kind
of understand what they're doing, kind of, you know, maybe similar to some virus scanner
stuff which can actually analyze the data within, like, you know, applications or what
have you and identify a polymorphic attack or identify some kind of virus signature.
Now, the basic assumption that we've got to make is that there's always more than one
way to do it, especially in computer science, right?
I mean, you know.
How many ways can you, like, get that X equivalence there, right?
You know, there's three right there, but I bet you there's, like, at least several billion
more that you can probably do.
So, you know, we're going to embed that into our decoder so that it will be, you know,
stronger, you know, more able to withstand signature analysis, right?
So I mean, if I needed to calculate pi or I needed to calculate X there, I could, you
know, alternatively select, you know, one of these mechanisms, you know, the decoder
itself.
The decoder itself, it isn't just one decoder.
It's like a decoder with, like, a tree kind of system that can alternatively select which
way it's going, you know, on a random basis.
And you can extend that if you feel that you found another way to, like, add one to a register.
You can just kind of, like, add that instruction in there and, you know, it can do that.
There are also alternate instructions.
There are also alternate instructions.
There are alternate paths.
So that, you know, if we need to calculate N, we can use, you know, various values that
we have also to calculate that.
There's a read me with the distribution.
If you read the read me, it goes into, like, a little bit more technical details of exactly
what's going on.
And, of course, you can always just kind of read the source that will tell you exactly
what's going on.
I clicked already, but this thing's kind of lagged out.
But, non-operational code padding.
This is the euphemism that I use to identify this expansion here.
You see L plus A plus M equals E. But, I mean, that's functionally equivalent to, like,
L plus, like, you know, bracket one plus one minus two plus A, you know, all this other
bracket stuff, which, you know, nulls out in the end of the equation and you still wind
up with E.
So, you know, we've got lots of these nulls.
So, you know, we've got lots of these nulls.
So, you know, we've got lots of these nulls.
So, you know, we've got lots of these non-operational padding instructions that will appear in
there.
These are the things that you will tune to your likeness, you know.
I don't know.
On Intel, I've had success with, you know, as much as you want, right?
It's your tolerance.
The more pads that you incorporate, the more space you've got to take up on the knob sled,
right?
So, you've basically got to tune that feature ahead of time.
It's kind of what you were talking about earlier.
Also, this padding is random.
randomly generated based on your specifications
in the API, right?
Like if you say no, again, the same thing.
The two upper, two lower is base kind of stuff
or carriage return, whatever.
You know, you'll ban this stuff in the beginning
and then we'll like add X, X or X,
or like jump nowhere to X location.
Things like that you'll be able to automatically generate.
Man, it's hot here.
Oh yeah, I've got some new functions in this release.
I actually initially released this polymorphic API
at the CanSec conference over in Vancouver.
I guess it's like DerSec also, www.dersec.com.
You can, right now the decoder also can appear
in like a out of order, you know, function.
So, let's see.
So, let's say there's five operations
that you need to have to decode the payload.
What you do ahead of time is kind of like
set up the structure and define like what positions
each instruction can enter into.
In this case, as you can see, one, two, three, four, five,
you know, one, three, two, five, four.
So, you know, if you need to,
so long as you're not altering the algorithm itself, right?
So a lot of instructions can appear in virtually any position.
I also added a weighted nop slide.
So if you have got like a hard-on for like, you know, printable ASCII characters in your
shellcode, you can like weight those nops to like a certain level.
Hey, hey, quiet.
Quiet up front here.
Yeah, I got a real hard-on for printable ASCII shellcode.
No, so you can say, I don't know, like if you had, if you were attacking something over
like a CGI listening on a web server, right, and, you know, HTTP traffic typically has
a lot of these angle brackets and stuff like that and whatever else, quotes and double
quotes and whatever else, right, HTTP, you know.
Those characters.
You can kind of weight those to whatever values you want.
Also this weighting will increase the variance in the API itself, right.
So if you just kind of go in there and randomly weight everything yourself, that will pretty
much mean that yours is a custom copy, right, and the codes that it generates are going
to be like more tuned to your preferences rather than the default ones.
So I mean if anyone, if any IDS vendor actually does create some kind of method to detect
this.
You should be able to effectively weight everything out and, you know, presumably,
you know, to your liking, it'll still be functional, but.
Again, here, you know, we, there's occasionally the requirement for certain shellcode restrictions
in your attack, right.
So you're going to be going along and you find out that your exploit requires too up
or too low a space or like any special cards banned out of this, right, so you just kind
of define that in the.
In this structure, you say, like, you flip some bits and you say, you know, hey, I want
this code to be too up or resilient or too low or resilient, and it'll go ahead and
do that for you.
If it doesn't, you know, then it'll, it'll tell you.
Currently, right now, I've got a 32-bit key that I use to encode everything and that's
just kind of like applied, you know, against everything one at a time.
I don't chain it or anything like that and, like, re, you know, any kind of crazy stuff.
I feel that that's enough.
It allows you to create a lot of permutations of the shellcode and, I mean, it's really
difficult to detect.
Again, I've got return address modulation, right, so, I mean, if you feel that, yeah,
I don't know, if, I mean, if the IDS vendor has a signature that'll detect against that,
you know, you can enable that and that might help out.
Okay.
What I was thinking about, I was, you know, I was thinking about implementing a sliding
key, so, you know, as you kind of encode each section, the key changes and the variants
get increasingly, you know, you get a lot more variants in your encoded shellcode.
You know, possibly can the sliding key be used to generate normalized shellcode to the
protocol which you're attacking?
You know, possibly, right?
I mean, I'm sure there's a way if you could develop an algorithm that can do that.
You know, you, your decoder might be a little bit bloated or big, you know, I don't really
know.
I haven't put too much effort into that right now, but there's definitely the possibility
in the future, right?
No matter what, there's always a way around, you know, any kind of detection mechanism
that anybody has.
I believe, you have a question back here?
Yeah, exactly, right?
So, yeah.
Okay.
So, the default weight of the members of the, like, decoder or the NOP substitutions,
right, is just one.
You know, you should just go in there and modify that yourself and have your own custom
version.
Yeah?
Well, you know, that's a possibility, right?
You know, it could be a little bit weaker, but I mean, like, if you had a protocol which
had, like, a lot of, like, you know, I don't know, hex 99 bytes in it, you know, you could,
like, weight that replacement a little bit more and it might be normalized compared
to the typical patterns.
The current implementation of this API, of this engine, actually, I created an API for
exploit developers, which is extremely easy to integrate into any exploit.
I mean, I took the LSD SNMP Solaris RPC vulnerability and I made, I just, like, called my three
functions.
I mean, you've got to be a little bit intelligent.
You need to be able to figure out exactly, like, where the boundaries are in the shell
code itself, right?
So, I mean, that isn't really too hard to figure out because, I mean, like, you know,
a few lines above that, they're going to be filling all that stuff in for you.
So, you know, it's really easy to integrate in source form, at least, into any exploitation
scripts that you got, right?
And I've also got a filter application for existing exploits.
Let's say you're a kiddie, you know, and you don't really know how to program anything
at all.
Yeah?
So, you can just pipe the output into this filter and then you're going to have to, you
know, select a few options.
You're going to have to tell the filter, like, okay, the NOP used in this exploit is, like,
hex 90.
There are, and then you're going to have to tell it the return address used in that
particular exploit so it knows when to stop encoding the shell code.
So with those two things, it kind of knows, okay, this is how many NOPs I've got, this
is how much shell code I've got to the boundary of, like, the return addresses and whatever.
We currently support IA32, Spark, and HPPA.
I tried to ‑‑ I actually limited all of these to, like, the most basic instruction
sets possible.
So, like, you know, Spark V8 and HPPA risk 1.1.
Just so, I mean, you're going to have the greatest leverage and, you know, potential
to attack target systems.
I'm sort of planning to do some MIPS, PowerPC, and alpha work.
I'm going to try to do that.
I don't know.
It's kind of up in the air right now.
I haven't really been doing too much work on this lately, but, I mean, if anyone wants
to write their own decoder, all you've really got to do is write a decoder, like, you know,
some assembly that does an XOR decode, right, pretty basic, and that's all you got to do.
Countermeasures.
That was the last slide.
I don't know.
There could potentially be some countermeasures.
I don't know.
There could potentially be some countermeasures for this stuff.
I heard some source fire guys or snort guys talking about some specific demons that they
could monitor on the wire, like, to detect all these patterns and what have you.
But, I mean, I'll believe it when I see it.
So, sorry, guys.
Yeah?
Is there a web page or something?
Yeah.
Yeah.
I...
Who's beepin' out?
Yeah.
K2.ca.
www.ktwo.ca.
Apparently this is an older version of my slide presentation.
I knew you used to have that in there.
Sorry.
This guy over here.
This ugly, ugly guy up here.
Well, what's my name?
What's my name?
That's your question, right.
In an antivirus scene, right...
You know, it comes in due.
self-mutating encryption generators and stuff
have been there for a long time.
But for example, if you're doing an enterprise-wide scan,
and an anti-virus scan taking 30 minutes is not a problem,
but an IDSS is more or less real time.
So there is a practical inherent limitation
in modus operandi when it comes to IDSS
and anti-virus software.
So what I'm trying to say is that the techniques
you present here would have actually a practical limit
when it comes to detection in terms of anti-virus
or IDSS software.
What do you think about that?
Man, I've got some serious power problems over here.
Well, I'm sorry.
I just need to...
You can analyze it, but you can't drop brackets, right?
You can, right?
And I mean, another benefit of exploits in the wild
using this kind of technology is that it's gonna increase
the processing power
to identify what's going on here, right?
And I mean, I've got things like...
Holy Jesus, man.
So I mean, I've got things that like, you know,
there's occasionally the need to exploit something
like hundreds of thousands of times per second
or whatever, right?
Like if you need to brute force an offset
of a respawning daemon or whatever, right,
and you've got only a small window to attack in.
I seed the random number generator
with the current time in seconds.
And then I add to that the add that the current,
your tick register or the lower 32 bits
of your tick register or your CPU.
So I mean, if you've got, you know,
I really don't see any way feasible like at all
that anyone could predict what is gonna come down the pipe
if you're seeding with your tick register
because for one, they're not gonna know your time,
and two, like the interval between at which you're gonna
reenter the function.
And you're gonna grab the tick register
is always gonna be slightly different
on a multi-tasking operating system, right?
So I mean, at one time, it might have taken
like 500,000 cycles.
Another time, it took like, you know, 500,001 cycles,
and that's just enough to like generate something different.
Joy?
I have a question.
Like, stuff like virus and anti,
Dr. Solomon and virus has actually
raised these issues in terms of anti-virus in the past.
But in the future, don't you see like there's a fundamental,
you know, there's a fundamental, you know, there's a fundamental,
challenge you have answered here.
When it comes to real time, you can't do this shit anymore
because there's so much processing power involved.
So in other words, you're like, you know,
like strike one for like idea software and...
Yeah, definitely.
I mean, the amount of processing power
that's gonna be required to identify.
Joy was alluding to the fact that this is a paradigm shift
in exploit development, right?
And if currently everybody's relying on these really
stupid, stupid exploits that go out, right?
Like stupid viruses that like, you know,
infect your boot sector and that's it.
You know, sit there memory resident.
But as soon as polymorphism came along,
it's kind of like enabled the viruses to have this endless
cat and mouse game, you know, going around in circles forever.
And, you know, that's still going on today.
So I mean, theoretically, this can go on
for a longer period of time and, you know, the amount of
of processing time that you're going to have to do to analyze the data as it comes across
the wire, especially with high speed, like, what, like, gigabit?
Like, IDSs can just barely handle gigabit right now.
So, I mean, I really can't see them handling gigabit and doing virtually any processing
on the data.
I know.
Put it up here on my box.
We'll detect it right now.
Yeah.
Yeah.
Okay.
And again, everybody, remember to tune your values, so, you know, you all have your custom
copy.
Okay.
It's in the structure.
It's the last member.
It's the last integer in the decoder structure, in the junk structure.
Just as a hint.
I've got a demonstration here that I intend to show.
It might have some surprising results.
I've got real secure, real secure coming here to analyze this.
You'll all really be really secure from now on.
Okay.
Here we've got the...
Here's the real secure console.
Okay.
Whoever the next speaker is, come up here and beat me if you really want to talk, because
I don't know how I'm doing for time.
20 minutes?
Okay.
I'm just going to grandstand for 20 minutes, if I can.
Okay.
I'll just be a second.
I'm going to set this up here.
I'm going to set this up here, and I'm going to go over here, and I'm going to do a couple
of exploit attempts from this Linux box to this Linux box on in this stupid hub down
here.
They're all kind of connected with this real secure box over here.
Stupid.
Stupid.
Okay.
Let's see here.
Oh, okay.
What I'm doing here is I'm going to imitate the IMAP protocol and, you know, some kind
of integer, login, space, login data, quotes.
There's some quotes around that login data.
And then you say pass.
This is what, you know, a typical IMAPs play.
And I mean, I'm sure we've all seen those before.
So I'm going to attack my box over here with my vulnerable IMAP, and we'll see what over
here, what real secure does about it.
Oh, whoops.
Whoops.
This here is the new version.
Okay.
Real secure did its job and secured us.
Thank you, real secure.
This product does actually work.
You know.
Suspicious TCP packet from the address here.
Essentially what I'm going to do is go through ‑‑ here's ‑‑ let me give you a little background
on why I'm, you know, going up against real secure here.
Initially after the CanSec conference, or DERSEC, like www.DERSEC.com, I ‑‑ everyone
started chatting about this a little bit, right?
And they're like, hey, you know, blah, blah, blah.
We are ‑‑ ISS released this big advisory saying, hey, we're not vulnerable.
This doesn't work.
I responded back, and I said, hey, yes, you are.
Could you please send me?
This is my quote up here.
I had asked for some technical details, TCP logs, et cetera, of an attack that was detected,
but none could be provided.
I have put it through some testing, and I have found that it is most definitely vulnerable
to these techniques, okay?
These are kind of taken out of context.
Okay.
And responded back to this ISS.net mailing list here by, let's see here, Tim Farley at
ISS.
Thank you, Tim.
He took me out of context here.
See, later on here, he's going, oh, this guy, me, admits he doesn't know what real
secure is supposed to detect in the first place, hence the request for the TCP logs.
No, Tim.
I'm asking for these logs.
So that I can verify what the hell is going on, and verify that you guys actually did
some work.
But none could be provided, and that's what I meant, that, you know.
He concludes that because it didn't detect something he threw in front of it, it must
be vulnerable.
No, no, no.
Well, yeah, man.
I don't know.
Anyway, he goes on here to, I mean, okay.
This product does detect a lot of stuff, okay?
I don't want to, you know.
Give him too bad of a name here, but, you know, it does detect buffer overflows, just
like he's saying.
It has a generic buffer overflow signature, which attempts to identify hex 90 in your
data.
But as we saw just now over here, it actually has a specific IMAP signature.
It's not the generic Intel signature.
I can show you that in a minute.
Real secure.
is not designed to attack, to detect attacks by recognizing the shell code. Okay, Tim.
Well anyhow, he goes on, I conclude that you use something that we don't have an XPU for,
I don't know what XPU means, but apparently it's something. And then, okay, two days later,
this by the way, this is all going on in a mailing list that I'm not a member of and
I didn't find this out until like months later, so I didn't have a chance to like respond
to any of this. And they're like, fucking A, man. This thing's just beeping like crazy.
So I didn't have a chance to respond to any of this, but luckily I was doing a Google
search of like my name and like mutate, so I was like, yeah, yeah, let's see how popular
I am, and I was like, yeah, yeah, yeah. No, but, no, someone CC'd me this. I disagree,
you've left out these key steps, right? Tim, this is from Tim again, Tim Farley, ISS Atlanta,
tfarley at ISS.net. Apparently his phone numbers have changed, so, I don't know. No,
actually, I've actually heard also that Tim is no longer with ISS after, and this is just
like two months old, so apparently, I don't know, there might have been a little abrasion
there because he's really abrasive towards me. So he left, he concludes that I left
out some key steps that I don't understand the scientific method.
Apparently, right? So, attempt an unmodified attack. Right here with the IMAP overflow.
Verify the IDS response to it. Okay.
Suspicious, yeah, IMAP, okay.
Attempt the modified version of, okay, okay, okay.
Tim, thanks, man. He just like worked himself right into this. Okay. What I'm doing here,
I'm doing the same thing I did before. You can't see that? Here, I'll get a second version
up there for you guys. There you go. As you can see, M7, like my favorite song, anybody
know what, anyone?
Freaking ThinkPad. Anybody know M7? Magnificent 7? Apparently, what you do with it, this is
the filter application, so it's going to take that same EXP that was run up there for, short
for exploit. M7.
That's pretty bad.
Here, I'll give you the help.
Word.
Word.
Apparently, you've got these four options here. I, S, M, or H. Short for Intel, Spark,
MIPS, or HP. The MIPS doesn't even exist in this code. I'll just put it there for fun.
I had the intention of coding that at the time when I wrote this.
And then what you do, so you select your architecture here, as you can see there, I did dash I.
This is the Intel overflow. And then you do dash O, the offset. So you tell the filter
when the offset values are going to, what they are, so it knows when to stop encoding,
because you don't want to encode those. Dash N, Nop. You've got to tell it what particular
knob you used, right? I mean, I know everyone uses 90, which is the official knob, but I mean,
there is the possibility that someone used something like the capital A, like cheese does
all the time. And then you do dash x exploit, or you could run the exploit pipe M7 if you wanted
to, because it accepts standard input if you don't do that. I just did that for fun, you know.
And then some other things here. Dash u, dash l, upper lower code. Dash b, give it a string
that's your string of band characters. Dash c, that'll output a c style array that you can just
kind of embed in some other code, or you can like take and analyze somewhere else.
Dash t will truncate the exploit attempt, because we know everybody's so damned lazy that they don't
actually know like how big the buffer was supposed to be, and they just kind of ram a bunch
of stuff.
down its throat. So you can typically—you can, like, nine times out of ten, truncate
this thing by, like, one or a hundred bytes, and it'll still function.
Dash P is to pad the encode-decode length. What this is, like, say I generated a decoder,
but, like, the jump offset was a banned character, you might have to, like, tell this filter
application to add some more bytes in there in the decoder so that you're not landing
in a banned character, like a too-upper, too-lower is based character.
Dash U is to attempt to modulate the offset back into the NOMSLED. This can be dangerous
because your SPLITE might not work because, you know, you could jump out of range.
So we're going to go through here and run this new SPLITE.
Oh, this guy is not a marketing person, neither is Chris Rowland, for that matter. Chris Rowland
actually made the initial response that ISS isn't vulnerable, you know, and he is an
engineer, apparently, and he has written many of the signatures in ReelSecure, so apparently
this guy is really in the know guy. Oh, it's a two-way street. Well, by the way, I actually
did send this code to ISS ahead of time before the public release, and they had a chance
to analyze it and everything, right? So I kind of see that as a two-way street, and
they didn't provide me with their logs, which I would have seen as a two-way street, so
I see some friction there. Yeah, I don't want to slam them, man, but you didn't have to
flame me without CCing me on the bloody mail, you know? I mean, I didn't even know
this was going on, and I'm getting flamed, so here you go.
So let's do this IMAP overflow and see what ReelSecure has to say about it.
Whoa! What's that? Sensor error. Holy shit. Oh, I didn't know this was going to happen.
I'm sorry. No, I'm kidding. Apparently, we just generated an exception fault in ReelSecure.
Well, I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry.
We all know what that means.
Oh, packet receive exception encountered in function hex 1004E360
in packet hash table, packet proto TCP, packet TCP UDP hash 000143.
So apparently, I don't know.
Let me think about this first.
Oh, okay.
Okay, this appears to be, I don't know, man.
I think for some reason,
RealSecure is attempting to diagnose the essence of the protocol here
and figure out what all this means to it.
No, I feel great that my packets mean a lot more to it than the IMAP did,
and it's thinking a lot harder about what to do,
and it just couldn't handle that, and it caused an exception.
So, okay, let's see.
Peter, you should be thinking more about structured exception handling, man.
I know, I was thinking about that, dude.
Boom.
I flashed myself.
So we'll do it again.
Another sensor error.
So this is a reproducible error, it looks like.
Well, well, I mean, I think this might be exploitable.
You know, it just seems to me, yeah, my laptop thinks so, too.
There you go.
Think back.
He's thinking a lot.
You know, so, this could, you know, that address we saw here,
what was that again?
Let's get the new one.
Okay.
Similar kind of thing, hash table, blah, blah, blah, blah, blah,
exception encountered calling this function.
It can't resolve the name of that,
so I'm assuming that it's overwriting some kind of function pointer,
something like that.
So, you know, if we could make some intelligent use of that
instead of just kind of random.
This is general.
This is designed to be random.
And, I mean, if we made some intelligent use
of what that randomness was coming over here,
you know, we could direct to the instruction flow of real secure.
Possibly, right?
I'm just thinking.
I could, I'll set up another demo here.
Just take a second.
I flashed my other.
Here we go.
Okay.
Let's do it on another port.
I'll explain this in a moment here.
Oh, fucking A.
Tricky.
I'm going to send it to port 110.
Okay, wait a minute.
Tim, Tim.
Okay, right.
Send an unmodified version.
Hold on a second.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
I just put that up there for the guys in the back.
Come on.
Give me a break.
Okay, so here's the unmodified exploit.
Wait a second.
Oh.
Huh.
Real secure.
I'm sorry.
.
I have to restart it.
It didn't have to be restarted, you think?
I tried it before and it didn't have to be restarted.
I think the deal with all this is crushing is, like, you know, shit's resolved when
it's processing and it's going to handle it.
Let me just try one more time.
Let me get rid of this quote here.
By the way, if you're making a .
And by the way if you're making a pop 3 access to this.
put a quote there and RealSecure is blind? No, I don't know. Do you think I can just
stop it from the console or do you think I have to reboot or something stupid like that?
I don't know. Okay, let's try that. Stop. Stop. Stop. Sorry for this lag, everybody,
but you know, this is NT I'm dealing with here. Bless you. Where? Oh, yeah. I mean,
I thought this was NT 4 for a second. There we go. Okay.
Okay, we restarted that. Okay. We'll come back in real...REAL
SECURE!
secure. Monitor, monitor, monitor. What the? Oh, fine. I don't know. Can you imagine what
kind of hassle this would be if you were running a live real secure? Okay, okay, let's see.
Connecting active. Connected, okay. So, I mean, you can all see what this does. User,
exploit code, going to port 110 of the vulnerable system that we saw events happening before,
so bless you. Okay, okay, I don't know. Whatever. We'll just call it quits on, we'll call it
it quits. Oh, I know what it might be. Here, I think we might need a space in there, another.
It did actually catch this before. It was, it, let me try a different port. Okay, so,
We'll try the FTP port.
Okay, ah, whatever.
Apparently real secure is having a hard time and we'll just let it have that hard time
on a four meter wide screen.
As you can see, I would have demoed, if it would have detected something, I would have
shown how it would have not detected something following that, but yeah, I'm having some
problems.
I could do it, I could like, here, what I can do, I'll do the IMAP one again just so
you can, all of you guys can see it.
You can see that the scanner is actually functional.
Was that it?
Yeah.
There we go.
Okay, so, you know, I don't know why those other ones weren't being seen whatsoever,
but who knows.
Let me do them a favor.
Let me check my policy and make sure that I'm clear.
I've got all the policies going on here.
Okay, let's see, apply to sensor.
Let's just, I'll just do this in front of everybody so that there's no question in
anybody's mind what it's doing.
This is version six, by the way.
So it just came out the other day.
Seriously, I was trying to like run my demo and then they like released a new version
on me and I was like, oh no.
Okay.
It is, it's like, apply to sensor.
Click, click, click.
What's that?
I don't know, it's not, it's not letting me click apply to sensor.
Does anyone know how to use Real Secure?
.
Reboot it, yeah.
Okay, this thing could just be foobar.
I mean, we could have just crashed enough stuff
so that it just can't handle what's going on anymore.
I don't know, right?
I mean, I'm trying to apply this stuff.
Any other questions as to how this is going to function
or anything like that?
Okay.
Oh, yep.
How much randomness do you really expect to have out of that?
Oh, good question.
In terms of the decoder section itself,
he asked how much randomness
do I expect to have out of the decoder.
Well, here.
If you see right here,
when I ran this code just now,
it deduced that this here is the original payload
and all of those blocks there are hex 90.
Over here,
we've got the fabled bin SH.
So, anyone can see that?
It figured out, okay,
I've got this much to encode, blah, blah, blah, blah, blah.
Almost nearly 3 billion keys.
So, nearly 3 billion possible outcomes.
So, that's 3 billion parts of
3 billion shellcode permutations, at least.
Here's the encoded shellcode.
This monitor isn't working in front of me,
so I gotta go off the big one here.
But here's the key we used, A2, blah, blah, blah, blah, blah.
And here's the encoded shellcode here, 54 bytes long.
The order of everything went 0, 1, 2, 3, 4, 5, 6,
oh, 6, 8, 9, 10, 11, 12.
I guess I can't see where 7 went either.
But.
As you can see, it's off to the side.
As you can see, it's out of order.
If I were to do this again, it could be in a different order.
And the hard-coded value that I used is,
I hard-coded a 42, a D, and this and that.
You see that the D there is a character
that you might have had to use that P option
to pad all this out with.
Here is the decoder engine itself, 73 bytes long.
And here is the actual polymorphic shellcode.
So this down here has this up here pre-pended
to the front of the stuff.
So let's run another one really quick.
And we'll see, see that the last one was 73,
this one is 66, so I mean, that's a fair difference.
And the order here is 0, 1, yeah, the other one went,
if I look up here, it went 0, 1, 2, 3,
it, oh, yeah, I don't know.
I mean, real secure, didn't cache it or something.
But 0, 1, 3, 2, so now you see the 3 and the 2
are out of order, 4, 5, 7, 8, and the 7, 8 are in order,
and the 6 is out of order, all this stuff.
So you can see it's kind of out of order,
the hard-codes are all different,
the length of this stuff is all different.
You can go in here.
Yeah, question?
When you code the shellcode,
what algorithm are you using?
Are you just using a simple XOR with the key?
I'm using a simple XOR,
with the key.
Question, could an IDS take a simple XOR
checksum of an even number of bytes
to identify the X-boy?
Because then the key would drop out.
X, what was that again?
Okay, okay, if they took the first 10 bytes of,
or if they took a particular 10 bytes of the shellcode,
right, and XORed them all together,
your key would drop out, no matter what the key was.
Why is that?
Because there's an even number of it in the XOR.
There's an even number of?
I mean, are you guys familiar at all
with the SMEG wire thing,
where they used to generate a lot of multiple encryption
generators and a lot of garbage instructions?
Okay, I see where you're coming from, but you can...
Is the same key that's XORed against every four-byte block?
Every four-byte block, yeah.
Against the same key XORed against it?
Yeah, I'm thinking about using a sliding key.
I mean, that's kind of the reason for that,
but I mean, this is just to evade current
and network intrusion detection.
So I mean, in the future, if anyone does detect it
by a mechanism like that, I mean, that's a good idea.
I mean, we can go ahead and add a couple extra instructions.
The problem is, is I really didn't want to take up
too much of the nop sled, right?
And I mean, every additional instruction I use,
potentially, is like another few bytes of space, right?
And I mean, this space is at a little bit more
of a premium than it is even in the virus coder world,
right, I mean, because like, you know,
one byte could mean the difference of getting root
and not getting root.
So I mean, I just don't want to make it too overly complex
to start, to begin with, right, so.
I guess they could do that.
Give it a shot, see how it goes.
See, right here, we say the maximum amount
of non-operational instructions.
By default, I use a four.
For Intel CISC CPUs, I found that three to 10
works really good, but for risks, you should probably
try and keep it to two to four, because in the risk systems,
it's always a 32-bit value.
So I mean, that's four bytes at a time.
Down here.
Here, let me test this here.
Here is the, this function itself is,
this here are the NOP replacements,
so basically this is a regular NOP,
this is a multi byte NOP that you can replace it with,
this is a single byte one.
These values here are all defined in the other header file,
You can look them up and figure out what it means.
But this last value here is the weight.
So this one is like a two, and this might be an old version, anyhow, this is the weight
here, or this is the weight, I don't know, whatever, look at the other header file and
it defines what everything is and you can figure out what all those integers mean and
then you can just go in there and tweak these values to your liking.
Any other questions?
You want to compare them and see if they're identical?
You would prefer that they're different?
Yeah but there are some sections of this code that are static.
So I mean, they are.
Okay, 1,004, E, 6, 0, is it the same, 1,004, 1,004, E, 6, 0, oh, whoops, yeah, it looks
like it's the same.
Okay, well, yeah, yeah, I mean, that could be right, right?
But I mean, there's a lot of static data also, and I mean, it could be reading the,
you know, offset section, which is the same every time, or it could be, I don't know
what it's doing, right?
I mean, I haven't like fully debugged it, but apparently we're smashing something, right?
And if we're smashing something, then that usually isn't the best thing to have go on.
Especially in the IES, yeah, yeah, as you said, duly noted.
Any other questions?
Questions?
Yes?
.
Yeah, hey, I'm going to give that a go.
The question was, you know, hey, are we going to have lots of stuff that will generate a
exploit and exploit the target system and the IDS simultaneously?
You know, hey, that's definitely a way we might want to move.
.
.
.
.
.
Recode any binary, I don't know man, I don't think too hard.
I mean, everything's pretty modular and tight, you know, anyone fairly familiar with C should
be able to like, you know, do whatever they want with the code.
I like to think that it isn't too sloppily written.
You know, there's a couple global variables that like my teach, my profs at some school
get pissed at me about, but I kind of need those, I like globals.
.
Anybody else?
Yeah, I'm just wrapped up.
I'm just doing Q&A.
Yep.
Pardon me?
K2.ca
slash security.html
Anybody else?
Five dollars.
Going once, going twice.
Okay, thank you.
